package com.stark.commons.lang.jdbc;

import java.io.Serializable;
import java.sql.PreparedStatement;

import lombok.Data;
import lombok.experimental.Accessors;

/**
 * 数据库连接配置项。
 * @author Ben
 * @since 1.0.0
 * @version 1.0.0
 */
@Data
@Accessors(chain = true)
public class DBOptions implements Serializable {
	
	private static final long serialVersionUID = 4523821158175004228L;

	/** 事务自动提交，默认 true */
	private boolean autoCommit = true;
	
	/** 建立连接等待时间，单位秒，默认 5 */
	private int maxWaitSeconds = DBAccess.MAX_WAIT_SECONDS;
	
	/** 建立连接重试次数，默认 3 ，小于 0 表示不限次数 */
	private int maxReconnectTimes = DBAccess.MAX_RECONNECT_TIMES;
	
	/** 连接存活时间，单位毫秒，默认 1000 * 60 * 5 */
	private int maxLiveTimeMillis = DBAccess.MAX_LIVE_TIME_MILLIS;
	
	/** 打印错误日志，默认 true */
	private boolean logError = true;
	
	/**
	 * System property that instructs Spring to ignore {@link java.sql.ParameterMetaData#getParameterType}
	 * completely, i.e. to never even attempt to retrieve {@link PreparedStatement#getParameterMetaData()}
	 * for {@link StatementCreatorUtils#setNull} calls.
	 * <p>The default is "false", trying {@code getParameterType} calls first and falling back to
	 * {@link PreparedStatement#setNull} / {@link PreparedStatement#setObject} calls based on well-known
	 * behavior of common databases. Spring records JDBC drivers with non-working {@code getParameterType}
	 * implementations and won't attempt to call that method for that driver again, always falling back.
	 * <p>Consider switching this flag to "true" if you experience misbehavior at runtime, e.g. with
	 * a connection pool setting back the {@link PreparedStatement} instance in case of an exception
	 * thrown from {@code getParameterType} (as reported on JBoss AS 7).
	 */
	private boolean shouldIgnoreGetParameterType = false;

}
